1. Field of Invention
The present invention pertains to the field of information management systems. More particularly, this invention relates to hierarchical information processes that share intermediate data and formulate contract data.
2. Art Background
Information management systems are commonly employed in a variety of business-related and other applications. Such information management systems typically include information stores such as database management systems. Such information management systems usually include and one or more information processes that manipulate data which is persistently stored in the database. Such information processes may also be referred to as applications. Information processes that perform extended duration information management functions may be arranged as a hierarchy of nested transactions.
FIG. 1 illustrates an information process 36 which is arranged as a hierarchy of nested transactions 30-32 in accordance with the prior art. The transaction 30 is at a top level of the process 36 hierarchy. The transaction 30 spawns the transactions 31 and 32. The transaction 30 is referred to as the parent of the transactions 31 and 32. The transactions 31 and 32 are each referred to as a child of the transaction 30. In general, such a nested hierarchy of transactions may continue down through many levels.
Typically, each of the transactions 30-32 performs some sort of information management function that generates data updates targeted for an information store 34. Typically, the transactions 31 and 32 provide their respective data updates to the transaction 30 upon their completion. The act of a child transaction providing its data updates to its parent is referred to as committing updates to the parent transaction or committing to the parent. Such transactions that commit their updates to their parent are usually referred to as closed transactions.
The data updates generated by the closed transactions 31-32 are usually interrelated. The transaction 30 usually acts as a repository for the interrelated data updates generated by the closed transactions 31 and 32. Typically, the transaction 30 commits to the information store 34 only after both of the closed transactions 31 and 32 have completed. A process wherein all child transactions are closed and wherein the parent transaction commits only after all its child transactions complete is referred to as a closed hierarchy.
The transaction 30 usually commits the data updates to the information store 34 using single atomic transaction. Typically, such an "atomic" or "flat" transaction ensures that the interrelated data updates generated by the transactions 30-32 are either all made visible or none are made visible in the information store 34 should a system failure occur. This usually ensures the integrity of the interrelated data generated by the transactions 30-32 as the data appears in the information store 34.
Under some circumstances a child transaction such as the transaction 31 may be of extended duration. For example, the transaction 31 may involve extended user interaction as well as communication to a remote site involving hours, days, and even weeks for completion. The transaction 32, on the other hand, may complete relatively quickly. Nevertheless, if the transaction 32 is a closed transaction then its data updates are held by the transaction 30 until the transaction 31 has completed. Such a hold up of data updates from the transaction 32 usually delays other information processes that may require the updated data generated by the transaction 32.
One prior technique for making the data updates of the child transaction 32 available to other processes prior to the completion of the process 36 is to allow the child transaction 32 to commit its data updates to the information store 34 directly. A child transaction that commits directly to the information store 34 is referred to as an open child transaction. Unfortunately, such direct writes to the information store 34 by a child transaction sacrifices the data integrity controls which are provided by a closed hierarchy. For example, a system failure after the transaction 32 commits to the information store 34 but before the transaction 30 commits can result in inconsistent data updates being visible in the information store 34.